ETSITS124 390V11.2.0 



(2013-04) 




Universal Mobile Telecommunications System (UMTS); 

LTE; 

Unstructured Supplementary Service Data (USSD) 

using IP Multimedia (IM) Core Network (CN) subsystem IMS; 

Stage 3 
(3GPP TS 24.390 version 11.2.0 Release 11) 



^ 



Advanced 



3^^. lie. 



A filOBAL INITIATIVE 



y 



3GPP TS 24.390 version 1 1 .2.0 Release 1 1 1 ETSI TS 1 24 390 V1 1 .2.0 (201 3-04) 



Reference 



RTS/TSGC-01 24390vb20 
Keywords 



LTE,UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2013. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS'^" and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 
2QppTM ^^^ LTETM are Trade Marks of ETSI registered for the benefit of its Members and 

of the 3GPP Organizational Partners. 
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 24.390 version 1 1 .2.0 Release 1 1 2 ETSI TS 1 24 390 V1 1 .2.0 (201 3-04) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 24.390 version 1 1 .2.0 Release 1 1 3 ETSI TS 1 24 390 V1 1 .2.0 (201 3-04) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 5 

1 Scope 6 

2 References 6 

3 Definitions, symbols and abbreviations 6 

3.1 Definitions 6 

3.2 Abbreviations 7 

4 USSD using IMS 7 

4.1 Introduction 7 

4.2 Description 7 

4.3 Operational requirements 7 

4.4 Coding requirements 7 

4.5 Signalling requirements 7 

4.5.1 General 7 

4.5.2 SDP Offer/Answer 9 

4.5.3 Activation/deactivation 9 

4.5.4 Invocation and operation 9 

4.5.4.1 Actions at the originating UA 9 

4.5.4.2 Actions at the AS 10 

4.6 Interaction with other services 1 

4.6.1 Originating Identification Presentation (OIP) 1 

4.6.2 Originating Identification Restriction (OIR) 1 

4.6.3 Terminating Identification Presentation (TIP) 1 

4.6.4 Terminating Identification Restriction (TIR) 1 

4.6.5 Communication Diversion (CDIV) 1 

4.6.6 Communication Hold (HOLD) 1 

4.6.7 Communication Barring (CB) 1 

4.6.8 Message Waiting Indication (MWI) 1 

4.6.9 Conference (CONF) 12 

4.6.10 Explicit Communication Transfer (ECT) 12 

4.6.11 Advice Of Charge (AOC) 12 

4.6.12 Closed User Groups (CUG) 12 

4.6.13 Three-Party (3PTY) 12 

4.6.14 Flexible Alerting (FA) 12 

4.6.15 Communication Waiting (CW) 12 

4.6.16 Completion of Communications to Busy Subscriber (CCBS) 12 

4.6.17 Completion of Communications by No Reply (CCNR) 12 

4.6.18 Customized Alerting Tones (CAT) 12 

4.6.19 Customized Ringing Signal (CRS) 12 

4.6.20 Personal Network Management (PNM) 12 

4.6.21 Malicious Communication Identification (MCID) 12 

4.6.22 SIP based user configuration 13 

4.7 Service configuration 13 

5 Extensions within the present document 13 

5.1 INFO Package for transport of USSD information 13 

5.1.1 Scope 13 

5.1.2 g.3gpp.ussd info package 13 

5.1.2.1 Overall description 13 

5.1.2.2 Applicability 13 

5.1.2.3 Info package name 13 

5.1.2.4 Info package parameters 13 

5.1.2.5 SIP options tags 14 



£75/ 



3GPP TS 24.390 version 1 1 .2.0 Release 1 1 4 ETSI TS 1 24 390 V1 1 .2.0 (201 3-04) 

5.1.2.6 INFO message body parts 14 

5.1.2.7 Info package usage restrictions 14 

5.1.2.8 Rate of INFO Requests 14 

5.1.2.9 Info package security considerations 14 

5.1.2.10 Implementation details and examples 14 

5.1.3 application/vnd.3gpp.ussd+xml MIME type 14 

5.1.3.1 Scope 14 

5.1.3.2 application/vnd.3gpp.ussd+xml 14 

5.1.3.3 Data semantics 15 

5.1.3.4 XML schema 15 

5.1.3.5 lANA registration 16 

5.1.3.5.1 Name 16 

5.1.3.5.2 Email 16 

5.1.3.5.3 MIME media type name 16 

5.1.3.5.4 MIME subtype name 16 

5.1.3.5.5 Required parameters 16 

5.1.3.5.6 Optional parameters 16 

5.1.3.5.7 Encoding considerations 16 

5.1.3.5.8 Security considerations 16 

5.1.3.5.9 Interoperability considerations 16 

5.1.3.5.10 Published specification 16 

5.1.3.5.11 Applications which use this media 17 

5.1.3.5.12 Applications that manipulate MIME typed objects (messaging, download etc.) 17 

5.1.3.5.13 Additional information 17 

5.1.3.5.14 Intended usage 17 

5.1.3.5.15 Other information/general comment 17 

5.1.3.5.16 Person to contact for further information 17 

Annex <A> (informative): Signalling flows 18 

A.l UE sending USSD request, no further information required 18 

A.2 UE sending USSD request, further information required from network 20 

Annex <B> (informative): Change history 24 

History 26 



£75/ 



3GPP TS 24.390 version 1 1 .2.0 Release 1 1 5 ETSI TS 1 24 390 V1 1 .2.0 (201 3-04) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

Y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the procedures for using Unstructured Supplementary Service Data (USSD) operations 
for mobile initiated MMI mode over IP Multimedia Core Network Subsystem (IMS). MMI mode is for the transparent 
transport of MMI strings entered by the user to the Application Servers (AS) and for the transparent transport of text 
strings back to the User Equipment (UE) to be displayed for user information. Support of USSD service is optional and 
only applicable for an operator's Public Land Mobile Network (PLMN). 

The present document is applicable to UE and AS which are intended to support USSD operations over IP Multimedia 
Core Network Subsystem (IMS) in mobile initiated MMI mode. 
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Release as the present document. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPPTR 21.905 [1]. 
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3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

AS Application Server 

IMS IP Multimedia core network Subsystem 

UE User Equipment 

USSD Unstructured Supplementary Service Data 

US SI Unstructured Supplementary Service Data over IM CN subsystem 



USSD using IMS 



4.1 Introduction 

This service provides the support for UE initiated MMI-mode USSD operations, which enables the transparent transport 
of MMl strings entered by the user to the IM core network and enables the transparent transport of text strings from the 
IM core network which are displayed by the UE for user information. 

4.2 Description 

There is no service description. 

4.3 Operational requirements 

There are no operational requirements. 

4.4 Coding requirements 

There are no coding requirements over and above those specified in 3GPP°TS°24.229°[6]. 

4.5 Signalling requirements 
4.5.1 General 

In the IM CN subsystem USSD messages can be transported in SIP INFO requests, SIP INVITE requests and SIP BYE 
requests, using a application/vnd.3gpp.ussd+xml MIME body. 

Figure 4.1 and figure 4.2 give an overview of the supported USSD operations: 



£75/ 



3GPP TS 24.390 version 1 1 .2.0 Release 1 1 8 ETSI TS 1 24 390 V1 1 .2.0 (201 3-04) 



UE USSI AS 

INVITE 
> 

language, ussd-String 

BYE 
< 

language, ussd-String 
BYE 



Error 



Figure 4.1 : UE initiated USSD operation, networit does not request further information 



UE USSI AS 

INVITE 
> 

language, ussd-String 

INFO 
< 

language, ussd-String 

INFO 
> 

language, ussd-String 
INFO 



- - -> 

Error 



BYE 

language, ussd-String 

BYE 



Error 



Figure 4.2: UE initiated USSD operation, networit requests further information 
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4.5.2 SDP Offer/Answer 

When a UE sends an initial INVITE request, in order to establish a USSD session, it shall include an SDP offer with 
one media description, according to subclause 6.1.2 of 3GPP TS 24.229 [6]. The UE shall add a zero port number value 
to the media descriptions of the SDP offer, in order to inform network entities that media resources are not requested for 
the session. 

When the US SI AS sends an SDP answer, it shall also add a zero port number value to any media description received 
in the associated SDP offer. 

4.5.3 Activation/deactivation 

4.5.4 Invocation and operation 
4.5.4.1 Actions at the originating UA 

NOTE 1 : The Content-Language SIP header field is not used to determine the language of the USSD string. Only 
the <language> XML element is used. 

In order to send the initial USSD message, the UE shall send an initial INVITE request, according to 
3GPP TS 24.229 [6]. The UE shall populate the request as follows: 

1) Request-URI set to a SIP URI with user part including the USSD string and and phone-context parameter set 
according to TS 24.229 [6], a host part set to the home netwok domain name used in REGISTER request as 
defined in TS 24.229 [6] a "user" URI parameter set to value "dialstring" as specified in RFC 4967 [7]; 

2) Recv-Info header field containing the g.3gpp.ussd info-package name; 

3) Accept header field containing the appUcation/vnd.3gpp.ussdH-xml, application/sdp and multipart/mixed MIME 
types; 

4) the Content-Type header, which shall contain "multipart/mixed"; 

5) SDP offer as described in subclause 4.5.2; and 

6) application/vnd.3gpp.ussdH-xml MIME body as described in subclause 5.1.3 with a Content-Disposition header 
field set to "render" and with "handling" header field parameter set to "optional". The XML document shall 
contain a single <ussd-string> element and may contain a <language> element. 

When receiving an INFO request with Info-Package header field containing the g.3gpp.ussd info-package and 
containing application/vnd.3gpp.ussdH-xml MIME body associated with the info package according to 
IETF RFC 6086 [2], the UE shall, in addition to the procedures specified in 3GPP TS 24.229 [6]: 

1) if the UE is able to process the received information, send an INFO request within the dialog, according to 
3GPP TS 24.229 [6]. The UE shall populate the INFO request as follows: 

a) Info-Package header field containing the g.3gpp.ussd info-package name; and 

b) application/vnd.3gpp.ussdH-xml MIME body as described in subclause 5.1.3, associated with the info package 
according to IETF RFC 6086 [2] containing the user's response in a <ussd-string> element and optionally a 
<language> element; and 

2) if the UE is not able to process the received information or rejects the received information, send an INFO 
request within the dialog, according to 3GPP TS 24.229 [6]. The UE shall populate the INFO request as follows: 

a) Info-Package header field containing the g.3gpp.ussd info-package name; and 

b) application/vnd.3gpp.ussdH-xml MIME body as described in subclause 5.1.3, associated with the info package 
according to IETF RFC 6086 [2] containing an <error-code> element. 

When receiving a BYE request containing application/vnd.3gpp.ussdH-xml MIME body, the UE shall, in addition to the 
procedures specified in 3GPP TS 24.229 [6] handle the application/vnd.3gpp.ussdH-xml MIME body. 
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NOTE 2: According to 3GPP TS 24.229 [6], the UE can receive a BYE request without the 

application/vnd.3gpp.ussd+xml MIME body and in this case the dialog is terminated immediately. 

4.5.4.2 Actions at the AS 

In addition to the procedures specified in this subclause, the USSI AS shall support the procedures specified in 
3GPP TS 24.229 [6] for an AS. 

NOTE 1 : The Content-Language SIP header field is not used to determine the language of the USSD string. Only 
the <language> XML element is used. 

Upon receiving an initial INVITE request with Request-URI containing the SIP URI including the USSD string and a 
"user" URI parameter set to value "dialstring" as specified in RFC 4967 [7], if the application/vnd.3gpp.ussd+xml 
MIME body contained in the request is accepted by the USSI AS, the USSI AS shall: 

1) pass the USSD data received in the body of the SIP INVITE request to the USSD application handling and wait 
for the response of the application; 

NOTE 2: How the USSD data are processed at the USSI AS is outside the scope of this specification. The USSI AS 
can handle the USSD dialogs or forward the USSD requests and responses to/from a legacy USSD server. 

NOTE 3: The USSD string in the request-URI is not passed to the USSD application handling. In case of 
discrepancy between this string and the <ussd-string> element contained in the MIME body, the 
behaviour of the AS is determined by the <ussd-string> in the MIME body. 

2) send 200 (OK) response to the request following the procedures specified for AS acting as a terminating UA in 
3GPP TS 24.229 [6]. The USSI AS shall populate the 200 (OK) response to the request as follows: 

a) Recv-Info header field containing the g.3gpp.ussd info-package name; 

b) Accept header field containing the application/vnd.3gpp.ussdH-xml, application/sdp and multipart/mixed 
MIME types; and 

c) SDP answer as described in subclause 4.5.2. 

Upon receiving an ACK request associated with the INVITE request, the USSI AS shall: 

1) if the network requests further information in order to perform the USSD operation, send an INFO request within 
the dialog created by the INVITE request. The USSI AS shall populate the INFO request as follows: 

a) Info-Package header field containing the g.3gpp.ussd info-package name; and 

b) application/vnd.3gpp.ussdH-xml MIME body as described in subclause 5.L3, associated with the info package 
according to IETF RFC 6086 [2] including a <ussd-string> element and a <language> element; 

2) if the network successfully performed the USSD information and does not need any further information, send a 
BYE request in order to terminate the dialog. The USSI AS shall populate the BYE request with 
application/vnd.3gpp.ussdH-xml MIME body, as described in subclause 5.L3 including a <ussd-string> element 
and a <language> element; and 

3) if the network informs the UE that the network is unable to process the USSD request or the network informs the 
UE that the network rejects the USSD request, send a BYE request in order to terminate the dialog. The USSI 
AS shall populate the BYE request with application/vnd.3gpp.ussdH-xml MIME body, as described in 
subclause 5.L3, including, a <error-code> element. 

Upon receiving a SIP INFO request with Info-Package header field containing the g.3gpp.ussd info-package and a 
application/vnd.3gpp.ussdH-xml MIME body associated with the info package according to IETF RFC 6086 [2], the 
USSI AS shall handle the SIP INFO request following the procedures specified for AS acting as a terminating UA in 
3GPP TS 24.229 [6] and generate a SIP response as described in 3GPP TS 24.229 [6]. If the SIP response is a 2xx 
response, the USSI AS shall: 

1) pass the USSD data received in the body of the SIP INFO request to the USSD application handling and wait for 
the response of the application; 
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NOTE 4: How the USSD data are processed at the USSI AS is outside the scope of this specification. The USSI AS 
can handle the USSD dialogs or forward the USSD requests and responses to/from a legacy USSD server. 

2) if the network requests further information in order to perform the USSD operation, send an INFO request within 
the dialog. The USSI AS shall populate the INFO request as follows: 

a) Info-Package header field containing the g.3gpp.ussd info-package name; and 

b) application/vnd.3gpp.ussdH-xml MIME body as described in subclause 5.1.3, associated with the info package 
according to IETF RFC 6086 [2] including a <ussd-string> element and a <language> element; 

3) if the network successfully performed the USSD information and does not need any further information, send a 
BYE request in order to terminate the dialog. The USSI AS shall populate the BYE request with 
application/vnd.3gpp.ussdH-xml MIME body, as described in subclause 5.1.3 including a <ussd-string> element 
and a <language> element; and 

4) if the network informs the UE that the network is unable to process the USSD request, or the network informs 
the UE that the network rejects the USSD request, send a BYE request in order to terminate the dialog. The 
USSI AS shall populate the BYE request with application/vnd.3gpp.ussdH-xml MIME body, as described in 
subclause 5.1.3, including, a <error-code> element. 

4.6 Interaction with other services 

4.6.1 Originating Identification Presentation (OIP) 

There are no interaction requirements with OIP. 

4.6.2 Originating Identification Restriction (OIR) 

There are no interaction requirements with OIR. 

4.6.3 Terminating Identification Presentation (TIP) 

There are no interaction requirements with TIP. 

4.6.4 Terminating Identification Restriction (TIR) 

There are no interaction requirements with TIR. 

4.6.5 Communication Diversion (CDIV) 

There are no interaction requirements with CDIV. CDIV is not applicable for USSI. 

4.6.6 Communication Hold (HOLD) 

There are no interaction requirements with HOLD. 

4.6.7 Communication Barring (CB) 

There are no interaction requirements with CB. CB is not applicable for USSI. 

4.6.8 Message Waiting Indication (MWI) 

There are no interaction requirements with MWI. 
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4.6.9 Conference (CONF) 

There are no interaction requirements with CONF. 

4.6.1 Explicit Communication Transfer (ECT) 

There are no interaction requirements with ECT. 

4.6.1 1 Advice Of Cinarge (AOC) 

There are no interaction requirements with AOC. 

4.6.12 Closed User Groups (CUG) 

There are no interaction requirements with CUG. 

4.6.13 Three-Party (3PTY) 

There are no interaction requirements with CUG. 

4.6.14 Flexible Alerting (FA) 

There are no interaction requirements with FA. 

4.6.15 Communication Waiting (CW) 

There are no interaction requirements with CW. 

4.6.1 6 Completion of Communications to Busy Subscriber (CCBS) 

There are no interaction requirements with CCBS. 

4.6.1 7 Completion of Communications by No Reply (CCNR) 

There are no interaction requirements with CCNR. 

4.6.18 Customized Alerting Tones (CAT) 

There are no interaction requirements with CAT. 

4.6.19 Customized Ringing Signal (CRS) 

There are no interaction requirements with CRS. 

4.6.20 Personal Network Management (PNM) 

There are no interaction requirements with PNM. 

4.6.21 Malicious Communication Identification (MCID) 

There are no interaction requirements with MCID. 
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4.6.22 SIP based user configuration 

Based on filter criteria, an initial INVITE request including a dialstring and an optional XML body as described in 
subclause 4.5.1 can be forwarded either to an AS supporting SIP based user configuration as specified in 
3GPP TS 24.238 [8] or to an AS supporting USSI as specified in this specification. 

An AS supporting USSI and SIP based user configuration as specified in 3GPP TS 24.238 [8], shall handle an initial 
INVITE request as described in subclause 4.5.1 according to this specification. 

NOTE: If an AS supports only SIP based user configuration as specified in 3GPP TS 24.238 [8], an initial 
INVITE request as described in subclause 4.5.1 is handled according to 3GPP TS 24.238 [8]. 

4.7 Service configuration 

User self configuration is not applicable to USSD using IMS. 



5 Extensions within the present document 

5.1 INFO Package for transport of USSD information 

5.1.1 Scope 

This subclause contains the information required for the lANA registration of info package g.3gpp.ussd in accordance 
with IETF RFC 6086 [2]. 

Editor's note: MCC needs to register this info package with lANA when 24.390 is published. 

5.1 .2 g.Sgpp.ussd info package 

5.1 .2.1 Overall description 

3GPP TS 24.390 describes the procedures for using Unstructured Supplementary Service Data 

(USSD) (3GPP TS 24.090 [3] and 3GPP2 X.P0065 [4]) operations in the IP Multimedia Core Network Subsystem 

(IMS). SIP INFO requests are used to carry information associated with USSD, using the g.3gpp.ussd info package. 

Every SIP INFO request associated with the g.3gpp.ussd info package carries a single application/ vnd. 3 gpp. us sd+xml 
MIME body associated with the info package according to IETF REC 6086 [2]. 

NOTE: According to the procedures in IETF RFC 6086 [2], the SIP INFO response will not contain a MIME 
body. A message associated with a USSD operation is always sent in SIP INFO request. 

In a given dialog, when a UA sends an INFO request associated with the g.3gpp.ussd info package, then until receiving 
an INFO request associated with the g.3gpp.ussd info package, the UA does not send another INFO request associated 
with the g.3gpp.ussd info package. 

5.1.2.2 Applicability 

This package is used to transport USSD information. 

5.1 .2.3 Info package name 

g.3gpp.ussd 

5.1 .2.4 Info package parameters 

None defined. 



ETSI 



3GPP TS 24.390 version 1 1 .2.0 Release 11 14 ETSI TS 1 24 390 V1 1 .2.0 (201 3-04) 

5.1.2.5 SIP options tags 

None defined. 

5.1 .2.6 INFO message body parts 

The MIME type of the message body carrying the information associated with USSD is appUcation/vnd.3gpp.ussd+xml. 
appHcation/vnd.3gpp.ussd+xml MIME type is defined in 3GPP TS 24.390. 

When associated with the g.3gpp.ussd info package, the Content-Disposition value of the message body carrying the 
information associated with USSD is "info-package". 

5.1 .2.7 Info package usage restrictions 

None defined. 

5.1 .2.8 Rate of INFO Requests 

No maximum rate or minimum rate is defined for sending INFO requests associated with the g.3gpp.ussd info package. 

For most USSD usages, normally zero, one, or a few, SIP INFO requests are generated in the SIP session by each 
participating user agent. 

5.1 .2.9 Info package security considerations 

The security is based on the generic security mechanism provided for the underlying SIP signalUng. No additional 
security mechanism is defined. 

5.1 .2.1 Implementation details and examples 

UAC generation of INFO requests: See 3GPP TS 24.390:" Unsti-uctured Supplementary Service Data (USSD) using IP 
Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3" 

Examples: See 3GPP TS 24.390: " Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core 
Network (CN) subsystem IMS; Stage 3" 

5.1 .3 application/vnd.3gpp.ussd-i-xml MIME type 

5.1.3.1 Scope 

This subclause contains the information required for the lANA registration of the application/vnd.3gpp.ussdH-xml 
MIME type in accordance with lANA registration procedures. 

Editor's note: MCC needs to register the application/vnd.3gpp.ussdH-xml MIME type with lANA when 24.390 is 
published. 

5.1 .3.2 application/vnd.3gpp.ussd-i-xml 

The MIME type is used to carry USSD related information between the UE and the network. It is coded as an XML 
document and contains one or more of the following information: 

- USSD language 

- USSD string 

USSD error code as defined in subclause 5.1.3.3 of this specification 
NOTE: The information elements cannot be present twice in the XML body. 
An instance of the XML document is shown below: 
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<?xml version="l . 0" encoding="UTF-8 " ?> 
<ussd-data> 

< language >en< /language > 

<ussd-string>*13 5#</ussd-string> 
</ussd-data> 

5.1 .3.3 Data semantics 

< language > is coded as defined in ISO-639. 

<ussd-string> is coded as a string. 

<error-code> is an integer. The following values are defined. If the received value is not listed below, it must be 
treated as 1. 

1 error - unspecified 

2 language/alphabet not supported 

3 unexpected data value 

<anyExt > contains optional elements defined by future version of this document. 

Entity receiving the XML body ignores any unknown XML element and any unknown XML attribute. 

NOTE : "unexpected data value" is used in case of interworking with the MAP protocol (i.e. in case such an error 
is received from the MAP interface). It is not used for the case where the string sent by the UE in 
response to a query from the network does not match any expected response. Procedures covering such 
cases are part of the USSD application handling. The application will usually send back another USSD 
string to the UE asking for a new input from the user or indicating that the transaction cannot be 
completed. 

5.1.3.4 XML schema 

Implementations in compliance with the present document shall implement the XML schema defined below. 

<?xml version="l . 0" encoding="UTF-8 " ?> 

<xs : schema xmlns : xs= "http : //www . w3 . org/2001/XMLScheina" 
eleTnentFormDefault=" qualified" 
attributeFormDef ault= "unqualified" > 
<xs: element name="ussd-data" > 
<xs : annotation> 

<xs : documentation> 

Unstructured Supplementary Services Data 
</xs : documentation> 
</xs : annotation> 
<xs : complexType> 
<xs : sequence> 

<xs:element name=" language" type="xs : string" minOccurs="0 " 
maxOccurs= " 1 " / > 

<xs:element name="ussd-string" type="xs : string" minOccurs="0 " 
maxOccurs= " 1 " / > 

<xs:element name="error-code" type="xs : int " minOccurs="0 " 
maxOccurs= " 1 " / > 

<xs: element name="anyExt" type="anyExtType" minOccurs="0 "/> 
<xs:any namespace="##other" processContents="lax" minOccurs="0 " 
maxOccurs= "unbounded" / > 

</xs : sequence> 

<xs :anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 
</xs : element> 

<xs : complexType name= " anyExtType " > 
<xs : sequence> 
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<xs:any namespace="##any" processContents="lax" minOccurs="0 " 
inaxOccurs= "unbounded" / > 
</xs : sequence> 
</xs : complexType> 

</xs : schema> 

NOTE: The AS can take the information received in the MIME body, formulate a MAP USSD message and route 
the message over SS7 to the USSD server via the HSS. Ahernatively, the AS can extract the USSD 
information from the received MIME body, and communicate with USSD server using other protocol. 

5.1.3.5 lANA registration 

NOTE: RFC 4288 [xy], subclause 9, states the process that applies in case of changes to the registry of media 
types. Any changes to the format or to subclause 5.1.3.5 after the registration with lANA would invoke 
this procedure. 

5.1.3.5.1 Name 

Editor's note: The name of the person responsible for the lANA registration needs to be added here. 

5.1.3.5.2 Email 

Editor's note: The e-mail of the person responsible for the lANA registration needs to be added here. 

5.1.3.5.3 MIME media type name 

Application 

5.1 .3.5.4 MIME subtype name 

Vendor Tree - vnd.3gpp.ussd+xml 

5.1.3.5.5 Required parameters 
None 

5.1.3.5.6 Optional parameters 
None 

5.1.3.5.7 Encoding considerations 

Binary. 

5.1.3.5.8 Security considerations 

The content of the MIME type can be used to trigger execution of supplementary services in a network. 

5.1 .3.5.9 Interoperability considerations 

The MIME type allows interoperability of USSD information between mobile networks and other systems. 

5.1.3.5.10 Published specification 
3GPP TS 24.390 
( http://www.3gpp.org/ftp/Specs/html-info/24390.htm ) 
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5.1 .3.5.1 1 Applications wliich use this media 

n/a 

5.1.3.5.12 Applications that manipulate MIME typed objects (messaging, download etc.) 

n/a 

5.1.3.5.13 Additional information 

1. Magic number(s): n/a 

2. File extension(s): n/a 

3. Macintosh file type code: n/a 

4. Object Identifiers: n/a 

5.1.3.5.14 Intended usage 

Common. 

The USSD is a very common service available on most mobile networks. The registration of the associated MIME type 
allows the USSD service to be incorporated in messages from other messaging systems. 

5.1.3.5.15 Other information/general comment 

n/a 

5.1.3.5.16 Person to contact for further information 

l.Name: TBD 

2. Email: TBD 

3. Author/Change controller: TBD 

Editor"s note: The name and e-mail of the person responsible for the lANA registration, and acting as author/change 
controller, needs to be added here. 
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Annex <A> (informative): 
Signalling flows 



A.1 UE sending USSD request, no further information 
required 

In the example flow at the figure A. 1-1, UE 1 sends a USSD request. The USSD application does not require further 
information, the USSD operation is successful and the AS hosting the USSD application indicates sends a USSD 
response towards UE 1 . 
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15. 200 (OK) ^ 




14. 200 (OK) ^ 





















Figure A.1-1 : UE sends USSD request 

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signaling flow. 
1. UE A sends INVITE request containing the USSD request 

UE sends the INVITE request. 
By including the Recv-Info header field, the UE indicates its support for the g.3gpp.ussd info package. 

Table A.1-1 : INVITE request (UE-1 to P-CSCF) 



INVITE sip:*135%23;phone-context=homel .netohomel .net ;user=dialstring SIP/2 . 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] : 1357 ;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net:7531;lr>, <sip:scscfl .homel .net; lr> 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service. ims . icsi .mmtel" 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <sip:*135%23 ; phone -context=homel .net ;user=dialstring> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 
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Require: sec-agree 

Supported: precondition, lOOrel, gruu 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; ealg=aes-cbc; spi-c=98765432 ; spi- 
3=87654321; port-c=8642 ; port-s=7531 

Contact : <sip :userl_publicl@homel .net ;gr=hdg7777ad7af lzig8sf 7>; +g. 3gpp . icsi- 
ref ="urn%3Aurn-7%3gpp-service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, INFO 

Accept: application/sdp; application/3gpp-ims+xml; application/vnd. 3gpp .ussd+xml 

Recv-Info: g.3gpp.ussd 

Content-Type: multipart/mixed; boundary=outer 

Content-Length: (...) 

--outer 

Content-Type: application/sdp 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio RTP/AVP 97 96 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 

--outer 

Content-Type : application/vnd . 3gpp . ussd+xml 

<?xml version="l . 0" encoding="UTF-8" ?> 
<ussd-data> 

< language >en< /language > 

<ussd-string>*135#</ussd-string> 
</ussd-data> 



Request-URI: in this example, the USSD message is *135#, and is represented as a dialstring. 

AppHcation/vnd.3gpp. ussd+xml MIME body: USSD message. The content of the <ussd-string> element included in 
the INVITE message must be equal to the dialstring inserted in the Request-URI. 

2. INVITE request (P-CSCF to S-CSCF) 

The P-CSCF forwards the INVITE request based on the Route header field. 

3. INVITE request (S-CSCF to AS) 

The S-CSCF forwards the INVITE request containing the USSD message based on iFC to the AS. 

4. 200 (OK) response (AS to S-CSCF) 

The AS sends a 200 (OK) confirming the receipt of the INVITE and to establish the dialog. The SIP 200 (OK) 
will contain a Recv-Info header field set to g.3gpp.ussd. 

5. 200 (OK) response (S-CSCF to P-CSCF) 

The S-CSCF forwards the 200 (OK) along the Via header field. 

6. 200 (OK) response (P-CSCF to UE) 

The P-CSCF forwards the 200 (OK) along the Via header field to the UE. 

7. ACK request (UE to P-CSCF) 

The UE responds to the 200 (OK) response with an ACK request sent to the P-CSCF. 

8. ACK request (P-CSCF to S-CSCF) 

The P-CSCF forwards the ACK request to the S-CSCF. 

9. ACK request (S-CSCF to AS) 
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The S-CSCF forwards the ACK request to the AS. 

10. USSD operation 

The AS performs the requested USSD operation. Details of USSD processing are outside the scope of this 
specification. 

In this example the USSD operation is successful and a response indicating success will be sent to the UE. 

11. BYE request (AS to S-CSCF) — see example in table A.1-2 

Table A1-2: BYE request (AS to S-CSCF) 



BYE sip : user 1 public lohomel . net ; gr=hdg7777ad7af IzigSsf 7 SIP/2 . 

Via SIP/2. 0/UDP sip:asl.homel.net,-branch=z9hG4bK332b23 .1 

Max-Forwards: 70 

Route: < sip:scscfl .homel .net; lr >, <sip :pcscfl .visitedl .net : 7531; lr> 

From: <tel: +l-237-555-3333>; tag=314159 

To: <tel:+l-23 7-555-llll>;tag=17182 8 

Call -ID: Cb03a0s0 9a2sdfglkj4 90334 

Cseq: 129 BYE 

Content-Type : application/vnd . 3gpp . ussd+xml 
Content-Length : 

<?xml version="l . 0" encoding="UTF-8" ?> 
<ussd-data> 

< language >en< /language > 
<ussd-string> 

Hello, your credit is $175.50. Thanks for your query. 
We are happy to assist. Your operator 
</ussd-string> 
</ussd-data> 



Application/vnd. 3gpp.ussd+xml MIME body: USSD message. 

12. BYE request (S-CSCF to P-CSCF) 

The S-CSCF forwards the BYE request to the P-CSCF. 

13. BYE request (P-CSCF to UE) 

The P-CSCF forwards the BYE request to the UE. The UE recognizes the apphcation/vnd.3gpp.ussdH-xml and 
displays the string. 

14. 200 (OK) response (UE to P-CSCF) 

The UE sends a 200 (OK) confirming the BYE request. 
15. 200 (OK) response (P-CSCF to S-CSCF) 

The P-CSCF forwards the 200 (OK) to the S-CSCF. 
16. 200 (OK) response (S-CSCF to AS) 
The S-CSCF forwards the 200 (OK) to AS. 

A.2 UE sending USSD request, further information 
required from network 

In the example flow at the figure A. 2-1, UE 1 sends a USSD request. The USSD application requires further 
information, and UE 1 sends further information in a USSD request. After the USSD operation is successful, the AS 
hosting the USSD application sends a USSD response towards UE 1. 
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Figure A2-1 : UE sends USSD request 

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the Dignaling flow. 
1. UE A sends INVITE request containing the USSD request 

UE sends the INVITE request. 
By including the Recv-Info header field, the UE indicates its support for the g.3gpp.ussd info package. 

Table A.2-1 : INVITE request (UE-1 to P-CSCF) 



INVITE sip: *135%23;phone-context=homel.net®homel .net ;user=dialstring SIP/2 . 
Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] : 1357 ;branch=z9hG4bKnashds7 
Max-Forwards: 70 
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Route : <sip :pcscf 1 . visitedl .net :7531;lr>, <sip:scscfl .homel .net; lr> 

Accept -Contact : * ; +g . 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <sip:*135%23 ; phone -context=homel .net ;user=dialstring> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Supported: precondition, lOOrel, gruu 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; ealg=aes-cbc; spi-c=98765432 ; spi- 
s=87654321; port-c=8642 ; port-s=7531 

Contact : <sip :userl_publicl@homel .net ;gr=hdg7777ad7af lzig8sf 7>; +g. 3gpp . icsi- 
ref ="urn%3Aurn-7%3gpp-service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, INFO 

Accept: application/sdp; application/3gpp-ims+xml; application/vnd. 3gpp .ussd+xml 

Recv-Info: g.3gpp.ussd 

Content-Type: multipart/mixed; boundary=outer 

Content-Length: (...) 

--outer 

Content-Type: application/sdp 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio RTP/AVP 97 96 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 

--outer 

Content-Type : application/vnd . 3gpp . ussd+xml 

<?xml version="l . 0" encoding="UTF-8" ?> 
<ussd-data> 

< language >en< /language > 

<ussd-string>*13 5#</ussd-string> 
</ussd-data> 
--outer— 



Request-URI: in this example, the USSD message is *135#, and is represented as a dialstring. 

AppHcation/vnd.3gpp. ussd+xml MIME body: USSD message. The content of the <ussd-string> element in the 
INVITE message must be equal to the dialstring inserted in the Request-URI. 

2. INVITE request (P-CSCF to S-CSCF) 

The P-CSCF forwards the INVITE request based on the Route header field. 

3. INVITE request (S-CSCF to AS) 

The S-CSCF forwards the INVITE request containing the USSD message based on iFC to the AS. 

4. 200 (OK) response (AS to S-CSCF) 

The AS sends a 200 (OK) confirming the receipt of the INVITE and to establish the dialog. The SIP 200 (OK) 
will contain a Recv-Info header field set to g.3gpp.ussd. 

5. 200 (OK) response (S-CSCF to P-CSCF) 

The S-CSCF forwards the 200 (OK) along the Via header field. 

6. 200 (OK) response (P-CSCF to UE) 

The P-CSCF forwards the 200 (OK) along the Via header field to the UE. 

7. ACK request (UE to P-CSCF) 

The UE responds to the 200 (OK) response with an ACK request sent to the P-CSCF. 
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8. ACK request (P-CSCF to S-CSCF) 

The P-CSCF forwards the ACK request to the S-CSCF. 

9. ACK request (S-CSCF to AS) 

The S-CSCF forwards the ACK request to the AS. 

10. USSD operation 

The AS performs the requested USSD operation. Details of USSD processing are outside the scope of this 
specification. 

In this example, the AS requires further information from the UE. 

11-13. INFO request (AS to UE) - see example in table A.2-11 

Table A.2-11 : INFO request (AS to S-CSCF) 



INFO sip: user l_publicl@homel .net ;gr=hdg7777ad7af IzigSsf 7 SIP/2 . 

Via: SIP/2 . 0/UDP ussias .homel .net : 6677;branch=z9hG4bKnashds75454 

Max- Forwards : 70 

Route : <sip:scscfl .homel .net : 46545, -lr>, <sip:pcscfl . visitedl .net : 75 31; lr> 

From: <sip:*135%23 ; phone -context=homel .net ;user=dialstring>; tag=t4 5 54 3 54 3 

To : <sip : userl_publicl@homel . net> ; tag=171828 

Call -ID: Cb03a0s0 9a2sdfglkj 490333 

Cseq: 4665 INFO 

Info-Package: g.3gpp.ussd 

Content-Length: (...) 

Content-Type : application/vnd . 3gpp . ussd+xml 

Content-Disposition : Info-Package 

<?xml version="l . 0" encoding="UTF-8" ?> 
<ussd-data> 

< language >en< / language > 

<ussd-string> 

Enter password: 

</ussd-string> 
</ussd-data> 



14-16. 200 (OK) response (UE to AS) 

The UE sends a SIP 200 (OK) to the AS confirming the SIP INFO request. 
17-19. INFO request (UE to AS) - see example in table A.2-17 

The UE sends the SIP INFO request containing the further USSD information required. 

Table A.2-17: INFO request (UE to P-CSCF) 



INFO sip:ussias. homel .net : 12456 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] : 1357 ;branch=z9hG4bKnashds76565465 

Max- Forwards : 70 

Route : <sip :pcscf 1 .visitedl .net:7531;lr>, <sip:scscfl .homel .net ; lr>, 

<ussias . homel . net : 6677 ; lr> 
From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <sip:*135%23 ; phone -context=homel .net ;user=dialstring>; tag=t4 5 54 3 54 3 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 128 INFO 
Info-Package: g.3gpp.ussd 
Content-Length: (...) 

Content-Type : application/vnd . 3gpp . ussd+xml 
Content-Disposition : Info-Package 

<?xml version="l . 0" encoding="UTF-8" ?> 
<ussd-data> 

< language >en< /language > 

<ussd-string> 
zAyExl973 

</ussd-string> 
</ussd-data> 
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20-21. 200 (OK) response (AS to UE) 

The AS sends a SIP 200 (OK) to the UE confirming the SIP INFO request. 

23. USSD operation 

The AS performs the requested USSD operation. Details of USSD processing are outside the scope of this 
specification. 

In this example, the USSD operation is successful and AS sends a response indicating success will be sent to the 
UE. 

24-26 BYE request (AS-UE) 

The AS sends a SIP BYE request towards UE containing a USSD response. 

Table A.2-2: BYE request (AS to S-CSCF) 



BYE sip : user 1 public lohomel . net ; gr=hdg7777ad7af IzigBsf 7 SIP/2.0 

Via SIP/2. 0/UDP sip : asl . homel . net ;branch=z9hG4bK332b23 . 1 

Max-Forwards: 70 

Route: < sip : scscf 1 . homel . net ; lr > , <sip :pcscfl .visitedl .net : 7531; lr> 

From: <tel: +l-237-555-3333>; tag=314159 

To: <tel: +1-237- 555- llll>;tag=171828 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90 3 34 

Cseq: 129 BYE 

Content-Type : application/vnd . 3gpp . ussd+xml 

Content-Length : 

<?xml version="l . 0" encoding="UTF-8" ?> 
<ussd-data> 

< language >en< / language > 
<ussd-string> 

Hello, your credit is $175.50. Thanks for your query. 
We are happy to assist. Your operator 
</ussd-string> 
</ussd-data> 



Application/vnd. 3gpp.ussd+xml MIME body: USSD message. 
27-29. 200 (OK) response (UE to AS) 

The UE sends a 200 (OK) to AS confirming the BYE request. 
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Version 0.0.0 TS Skeleton 


0.0.0 




2011-05 










Contains agreed P-CRs from CT1#71: CI -112245, Cl- 
112246 


0.0.0 


0.7.0 


2011-07 










Contains agreed P-CRs from CT1#72: CI -112934, Cl- 
112935, Cl-112956 


0.1.0 


0.2.0 


2011-09 










Contains agreed P-CRs from CT1#73:C1-113450, Cl- 
113451, Cl-113590, 


0.2.0 


0.3.0 


2011-10 










Contains agreed P-CRs from CT1#74: Cl-1 14351, Cl- 
114411 


0.3.0 


0.4.0 


2012-01 










Changes the structure of the TS in order to allow for 
collection of alternative proposals: existing material in 
main part and Annex A (signalling flows) are shifted to 
new Annex B. 

Contains agreed P-CRs from CT1#75: Cl-1 15144, Cl- 
115145, Cl-115146, Cl-115147, Cl-115148, Cl-115230. 


0.4.0 


0.5.0 


2012-01 










Editorial correction 


0.5.0 


0.5.1 


2012-02 










Contains agreed P-CRs from CT1#76: Cl-120685, Cl- 
120688, Cl-120693, Cl-120694, Cl-120884 


0.5.1 


0.6.0 


2012-05 










Contains agreed P-CR from CT1#77: Cl-121624 


0.6.0 


0.7.0 


2012-06 










Contains agreed P-CRs from CT1#78:C1-121884, Cl- 
122234, Cl-122236, Cl-122236, Cl-122237 


0.7.0 


0.8.0 


2012-06 


CT-56 


CP-1 20281 






Version 1 .0.0 created by IVICC for presentation to CT-56 for 
information 


0.8.0 


1.0.0 


2012-08 










Contains agreed P-CRs from CT1#79:C1-122529, Cl- 
123260, Cl-123261, Cl-123267, Cl-123353, Cl-123420 


1.0.0 


1.1.0 


2012-08 










Editorial cleanup 


1.1.0 


1.1.1 


2012-09 


CT-57 


CP-1 20608 






Version 2.0.0 created by IVICC for presentation to CT-57 for 
approval 


1.1.1 


2.0.0 


2012-09 


CT-57 








Version 1 1 .0.0 created by MCC after approval at CT-57 


2.0.0 


11.0.0 


2012-12 


CT-58 


CP-1 20800 


0002 


3 


USSI Cleanup of Alternatives 


11.0.0 


11.1.0 


2012-12 


CT-58 


CP-1 20800 


0003 


2 


USSI interaction with SIP user configuration 


11.0.0 


11.1.0 


2012-12 


CT-58 


CP-1 20800 


0013 


1 


Clean up of encoding USSD information as an XML 
document 


11.0.0 


11.1.0 


2013-03 


CT-59 


CP-1 301 05 


0014 


2 


Clarifications and Corrections to USSI 


11.1.0 


11.2.0 


2013-03 


CT-59 


CP-1 301 05 


0015 


4 


USSD Procedures clarifications and corrections 


11.1.0 


11.2.0 
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